IsUniqueID

Setting IsUniqueID to true for an Element in a Group indicates that this Element holds the globally unique identifier for the “thing” described by an instance of the Group.

Each Group (after all inheritance has been taken into account) can have either zero or one Elements which has IsUniqueID set to true.

Some explanatory notes / examples for MXF:

• In MXF Header Metadata all Groups are descended from “InterchangeObject” which has an Element called “InstanceID”.
• An instance of a Group is an Object.
• Each Object can be regarded as a “metadata record” that contains metadata about a “thing” (the “thing” could be a piece of video essence, a person, a location, etc)
• The value of an Object’s “InstanceID” Element is an identifier for the Object – that is, it is an identifer for the “metadata record”.
• If the Object has an Element which has IsUniqueID set to true then this Element contains the globally unique identifier for the “thing” that the Object (aka “metadata record”) describes.
• There could be more than one Object in an MXF file that describes the same “thing”. Each Object will have its own unique “InstanceID” but this does not prevent them from all referring (using the value of some other Element) to the same “thing”.
• This explains why IsUniqueID is not set to true for the “InstanceID” Element: it is a “metadata record” identifier not the identifier of the “thing” that the “metadata record” is actually about.

Constraints are placed on the use of IsUniqueID by:

• the “WeakReference” TypeKind (see below)
• the use of a Group within a “Set” (what MXF calls a “batch”). If strong or weak references to instances of a Group are to be included in a “Set” then the Group must have exactly one (after inheritance) Element that has IsUniqueID set to true. Although the logical meta-model requires this it does not seem to be explicitly required by ST 377-1 and indeed not complying with this is not really a problem in MXF because all instances of Groups have “InstanceID” values anyway (at least in the Header Metadata). For some existing Groups it seems as though the metadata design does not actually meet the above requirement anyway (e.g. in DMS-1 the “Titles” Group seems to be without a unique identifier even though it is included in a Set / “batch”). Therefore, this constraint is not enforced.

Many-to-one relationships

Many entities have “non-exclusive” relationships with other entities. So, entity A could “non-exclusively” reference entity B, and entity B could be “non-exclusively” referenced by entities C, D, and E as well. This is a many-to-one relationship.

Such relationships can be implemented using any data type e.g. entity B could contain a “String” property that contains a URL (which uniquely identifies entity B) and entity A could reference entity B using the value of this URL.

“WeakReference”

“WeakReference” is a TypeKind in the Registers. An Element with a Type that has a TypeKind of “WeakReference” contains a “non exclusive” (many-to-one) reference to an Object. So, more verbosely it is a “Weak Object Reference”. It is just one way in which to implement a many-to-one relationship in the Registers. Not all many-to-one relationships in AAF & MXF (nor in the Registers more generally) are implemented using Types with a TypeKind of “WeakReference”.

Facets are optional for Types with a TypeKind of “WeakReference”. If present they have to describe the “Target List” (see the AAF Object Spec).

Each Type with a TypeKind of “WeakReference” must state the target Group of the reference using the BaseType field. References can be made to instances of this Group or its descendants / sub-classes. The Group stated by the BaseType field (after all inheritance has been taken into account) must have exactly one Element with IsUniqueID set to true. The safest choice (for maximum interoperability) for the Type of this Element is “AUID”. However, “UUID” or “PackageIDType” (which is a UMID) should also be OK.

The complexities and confusion around “WeakReference” mean that Registers entries designers are strongly discouraged from using it unless it is absolutely essential and its use is fully understood and appropriately documented.

AAF

The intention is that all Types in the Registers that are used in AAF and have a TypeKind in the Registers of “WeakReference” map to AAF “Weak Reference Type Definitions”. In AAF these many-to-one relationships are always between Objects in the same AAF file.

MXF

The Object referencing situation described in ST 377-1 is hard to follow and certain parts of the document seem to contradict one another.

A Type in the Registers that is used in MXF and that has a TypeKind in the Registers of “WeakReference” is sometimes, but not always, what ST 377-1 seems to describe as a “Weak Reference”. Additionally, when the Type is used in an MXF standard there may simply be a statement of the underlying data type used to realise the reference in an instance value and there may be no explicit mention of “references” at all.

In MXF, the data type of an instance value of a Type with TypeKind “WeakReference” is always the same as the data type of the Element which has IsUniqueID set to true in the referenced Group (see below for exceptions…). Example:

• Object X contains metadata about a person P.
• The unique identifier for P is a UUID.
• Object X contains Element E which has IsUniqueID set to true and the Type UUID. Element E contains the unique indentifier for P.
• Type T has TypeKind “WeakReference” and its BaseType field contains the UL for the Group of which Object X is an instance.
• An Element (in another Object) could use Type T and the Element could contain the UUID of Person P (or the UUID of another Person). Note: it would NOT contain the “InstanceID” of Object X

MXF Exceptions to the above – note that these exceptions apply specifically to how an instance value is encoded in an MXF file:

• The Element “PrimaryPackage” (urn:smpte:ul:060e2b34.01010104.06010104.01080000) has Type “PackageWeakReference” which has TypeKind “WeakReference” and BaseType “Package”. However, when encoded in an MXF file an instance value of this Element has data type “UUID” and contains the value of the “InstanceID” of the Object which describes the “Primary Package”. This is exceptional behaviour: the standard behaviour would be for an instance value of this Element to have data type “PackageIDType” (which is a UMID) because in the “Package” Group the Element with IsUniqueID set to true is “PackageID” and this has Type “PackageIDType” (which is a UMID). Note: this exception is tied to the Element “PrimaryPackage” and so would not necessarily apply to other uses of the Type “PackageWeakReference”.

Reg-XML

“InstanceID”

The MXF Element “InstanceID” can be treated in exactly the same way as any other Element and included in the Reg-XML output as normal. The only reason to leave this Element out is because of one statement in ST 2001-2 that says to do this. Following this requirement of ST 2001-2 could be appropriate if a Reg-XML document is needed that conforms to the currently published 2001-2 Baseline (that is, an AAF-centric view of the data). Note that many other actions will also need to be taken in order to achieve this goal other than simply leaving out the “InstanceID” Element.

reg:uid

The purpose of this attribute is to be the XML-friendly (and potentially human friendly) unique identifier for the “thing” that an Object / “metadata record” describes. This is to be used principally as the target of Elements that have a Type with TypeKind “WeakReference”. Include reg:uid on an instance of a Group if, and only if, that Group contains an Element with IsUniqueID set to true. The value of the reg:uid attribute must be the value of the Element that has IsUniqueID set to true.

Reg-XML value for an Element with a Type whose TypeKind is “WeakReference”

The Reg-XML value for an Element with a Type whose TypeKind is “WeakReference” must be the value of the Element with IsUniqueID set to true in the referenced Group. There are currently no exceptions to this rule – this must be followed even if this is not how the Element instance value is encoded in an MXF file.

Given the explanation above, this means that translating an Element instance value from MXF to Reg-XML is very simple (apart from the listed MXF exceptions): for an Element that has a Type whose TypeKind is “WeakReference” the Reg-XML value will simply be the value that the Element has in the MXF file.

Translating identifiers

The values used for both reg:uid attributes and Elements with a Type whose TypeKind is “WeakReference” can be “translated” if required. For example, instead of including UL values for “Labels” in the Reg-XML output the UL could be looked-up in the Labels Register and the namespaced symbol used instead.

Note that a translation would be mandatory if the data type that would otherwise be used is not permitted as an XML attribute value (for example if a Group had an Element with IsUniqueID set to true and the Type of that Element had the TypeKind “VariableArray”). However, in reality this situation could never arise for MXF.